Supporting aspect-oriented software development with the Concern Manipulation Environment

componentsThe CME architecture is illustrated in Figure 4.Abstract components, introduced in bold italics inthe text, are the first-order open-points of the CMEarchitecture. Each plays a distinct role in realizingthe extraction/composition cycle. These compo-nents are described by their APIs (applicationprogramming interfaces), and their implementationsdepend only on the APIs of the other components.Abstract factories are used to shield clients and othercomponents from knowledge of the implementationclass structure within a component. The CME alsoincludes concrete instances of these components toprovide both basic functionality and examples ofimplementation. The initial set of concrete compo-nents in the Eclipse project are themselves generallydesigned to be extended with strategies and plug-ins, giving rise to a second-order set of open-points. This paper can describe neither the concretecomponents nor the strategies and plug-in oppor-tunities they present in great detail. However, suchdetails can be found in the collection of researchreports comprising References11–14. Support for manipulation of concern-structuredsoftware in the CME corresponds to the extraction/composition cycle discussed previously. The Con-cern Manager component, shown in Figure 4,provides a starting point for discussion. The Con-cern Manager is the (abstract) component used tohold and manipulate a model that identifies con-cerns and describes both the units of software theycontain and their relationships. Units representsoftware artifacts, like classes, methods, or UML**(Unified Modeling Language) diagrams. Concernshere are groups of concern model elements, listedexplicitly (extensionally) or specified as queries(intensionally). Relationships can be derived fromsoftware artifacts, such as references or depen-dencies, or inserted by tools, for example, in casesFigure 4Partial CME component architectureSpecialized Loaders AspectJCIT/CAT APIArtifacts